Combined Alarm Log File Reporting Using XML Alarm Token Tagging 



Field of the invention 

[01] The invention relates to communications network management, and in particular 
to alarm information reporting methods. 

5 Background of the invention 

[02] In the field of communications network management alarm reporting is 
important both in addressing immediate fault management issues related current 
infrastructure failures, and in the larger context of statistics reporting and network 
planning. 

10 [03] In a managed communication network context, large numbers of 
communications network nodes generate very large numbers of alarms which are 
logged. The alarm logs are collected into log files, the log files are subsequently 
interpreted, and the results are displayed to network management personnel interacting 
with network management equipment such a Network Management System (NMS). 

15 Efficient parsing of the log files in interpreting thereof, is important because of the large 
number of alarms and log files. Shortcomings in this regard represent large and costly 
operational network management overheads in provisioning communications services. 

[04] Complications arise from a lack of consistency in respect of alarm reporting. 
While attempts have been made to mitigate deficiencies, current solutions are either 
20 vendor specific addressing vendor specific needs and issues, or not widely adopted. 
Specifically shortcomings stem from: 

- the absence of a common format for alarm reporting; 

- the requirement to address multiple network management needs concurrently; 

- the absence of a common format for log files; 



1 



- the difficulty in timely providing documentation regarding alarm reporting and 
file formats employed for timely development and/or update of alarm management 
tools; and 

- the onerous requirement to provide alarm management tools to take advantage of 
5 newly reported alarm information. 

[05] In referring to a common format for alarm reporting, one understands an alarm 
report to include a sequenced group of tokens which specify in respect of an alarm, 
without being limited thereto: an alarm name, an alarm type, an alarm severity, an 
equipment component specification, a comment, etc. The sequence of the alarm tokens 
10 relates to the identification of the tokens. Each alarm report requires a different 
combination of such alarm tokens to fully convey the full meaning of the alarm and to 
distinguish it from others stifling any attempts towards alarm report standardization. 

[06] Network management functions, in addressing different aspects in responding to 
an alarm, require different sub-combinations of reported alarm tokens. Trying to 
15 address all network management functions with the same alarm report restricts 
independent development of network management functionality. 

[07] In order to support independent development of network management 
functionality, alarm reports are typically logged in different log files only with the 
necessary sub-combination of tokens needed to implement the network management 
20 functionality. However the practice introduces an alarm reporting overhead associated 
with reporting the same alarm multiple times, and further introduces complexities 
related to log file management. 

[08] Log files employed to support different network management functionality 
typically have different log file formats in respect of internal file structure including log 

25 file headers, the alarm log body, and any log file trailers. For example, the structure of a 
log file dictates the location where alarm reports start and end. Further alarm log file 
formats specify the manner in which alarm tokens are delimited such as: quote-comma 
delimiters wherein complex tokens containing spaces are placed between quotation 
marks and a coma is used between tokens, tab delimiters wherein complex tokens may 

30 include spaces and the tab character is used between tokens, etc. 
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[09] Communications network equipment development includes multiple 
independent efforts of multiple communications network equipment vendors, wherein 
documentation has to be provided in respect of each effort for: each change in reporting 
an alarm, each new alarm, in respect of existing and newly developed communications 
5 network equipment. A development overhead is incurred in producing the 
documentation which is required to take into account the diverse network management 
functionality provided by network management systems. 

[10] The onerous requirement to provide alarm management tools to take advantage 
of newly reported alarm information relates to the diverse network management 
10 functions which are provided by a network management system. All network 
management functions have to be re-coded for each change in reporting an alarm, for 
each new alarm, for each change in a log file format, etc. in respect of existing and 
newly developed communications network equipment. In this respect, specialized log 
file parting code must be developed and updated with each alarm reporting change. 

15 [11] To date the most notable effort towards mitigating alarm reporting relates to an 
International Telecommunications Union Recommendation X.733 entitled "Information 
Technology, Open Systems Interconnection - System Management: Alarm Reporting 
Function" 1992 which is incorporated herein by reference. The X.733 recommendation 
specifies a mechanism for reliable alarm transport and relates to formatting tokens 

20 without addressing alarm report formatting nor alarm log file formatting. As a 
particular example the X.733 specification describes alarm token formats for: 





Probable cause 


M; 




Specific problems 


U; 




Perceived severity 


M; 


25 


Backed-up status 


U; 




Back-up object 


C; 




Trend indication 


U; 




Threshold information 


C; 




Notification Identifier 


U; 


30 


Correlated notifications 


U; 




State change definition 


U; 




Monitored attributes 


U; 




Proposed repair actions 


U; 




Additional text 


U; 


35 


Additional information 


U; 



etc. 
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wherein "M" denotes a mandatory token; "IT denotes the token as a service-user 
option; "C" denotes a conditional token, conditions being defined by the text describing 
the token; "P" denotes a token having a value which is subject to constraints imposed by 
CCITT Recommendation X.710 / ISO/IEC 9595. In order use the Rec. X.733 both the 
5 communications network equipment issuing alarm reports and the network management 
systems receiving the alarm reports have to employ the specification, agree on alarm 
report formats and alarm log file formation which are considered beyond the scope of 
the X.733 specification. 

[12] There therefore is a need to solve the above mentioned issues. 

10 Summary of the invention 

[13] In accordance with an aspect of the invention, a method of reporting an alarm is 
provided. The method includes encapsulating each alarm token reported in respect of 
the reported alarm, between a corresponding pair of extensible Markup Language 
(XML) tags. 

15 [14] In accordance with another aspect of the invention, a method of parsing an alarm 
report is provided. The method includes identifying alarm tokens constituent of the 
reported alarm by inspecting XML tags encapsulating each alarm token. 

[15] In accordance with a further aspect of the invention, each XML tag specifies 
compliance with one of a standard and a recommendation. 

20 [16] In accordance with a further aspect of the invention, each XML tag specifies an 
alarm type. 

[17] In accordance with yet another aspect of the invention, each XML tag specifies 
an alarm token name. 

[18] Advantages are derived from a communication equipment development 
25 independence, a network management system development independence, a network 
management function development independence, employing a single alarm log file for 
concurrently reporting alarms for multiple network management functions at reduced 
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alarm reporting overheads, an operational resilience of a network management system in 
respect of a newly reported alarm token in respect of an existing alarm, an operational 
resilience of the network management system in respect of a newly reported alarm, and 
only the network management functions requiring a particular no longer reported alarm 
5 token in processing an alarm being affected. 

Brief description of the drawings 

[19] The features and advantages of the invention will become more apparent from 
the following detailed description of the exemplary embodiment(s) with reference to the 
attached diagrams wherein: 

10 FIG. 1 is a schematic diagram showing elements exchanging alarm reporting 

information, in accordance with the exemplary embodiment of the invention, in a 
managed communication network. 

[20] It will be noted that in the attached diagrams like features bear similar labels. 

Detailed description of the embodiments 

15 [21] Solutions are sought towards easier alarm and notification management in a 
managed communications network context. Reference is made to FIG. 1 throughout the 
present description. 

[22] In accordance with as embodiment of the invention, each alarm token of an 
alarm report 100 is encapsulated in extensible Markup Language (XML) tags having a 
20 format. The format of the XML tags specify: 

- alarm token compliance with a specific standard/recommendation such as, but 
not limited to the ITU X.733 Recommendation, 

- the X.733 alarm type, and 

- the alarm token name, 
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and therefore accordingly the XML tags employed specify the encapsulated token data 
thus aiding in parsing 200 alarm log files 102. 

[23] Such an exemplary alarm log file 102 would include: 

<header>first log file</header> 

5 <body> 

<notification> 

<_uptime_MOI>edgeNode67</_uptime_MOI> 

<_uptime_Duration>00:00:02</__uptime_Duration> 

</notification> 

10 <alarm> 

<X.733_collision_MOI>0.1.7.1.3</X.733_collision_MOI> 
<X.733_collision_GMTtime>12:00:02<X.733_collision_GMTtime> 
<X.733_collision_Availability>99</X.733_collision_Availability> 
<X.733_collision_Severity>low</X.733_collision_Severity> 
15 </alarm> 

</body> . 

[24] Accordingly, specific XML tag definitions are published, so that 
communications equipment vendors implement the XML tags in alarm reporting 
functions 104 and therefore for inclusion in alarm log files 102. 

20 [25] Therefore in accordance with the exemplary embodiment of the invention, 
encapsulating alarm tokens within XML tags, enables employing standard XML parsing 
tools (200) in interpreting alarm log files 102 at a Network Management System (NMS) 
204. Only the XML tag definitions are necessary in parsing alarm log files 102 
generated in accordance with the exemplary embodiment of the invention. 

25 [26] In accordance with the exemplary embodiment of the invention, shortcomings 
with respect to a common format for alarm reporting are addressed by encapsulating 
alarm tokens within XML tags reducing stringent requirement with respect to the 
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different combinations of alarm tokens to fully convey the full meaning of a reported 
alarm and to distinguish the alarm from others. The XML tags specifically specify 
which alarm is being reported in terms of XML tag identified tokens therefore the 
otherwise stringent alarm token sequencing requirements are relaxed. 

5 [27] In accordance with the exemplary embodiment of the invention, network 
management functions 204 may regard alarms to be specified by name and sub- 
combinations of alarm tokens reported in a single alarm log file 102, therefore reducing 
alarm reporting overheads. Multiple network management functions 204, registered 
with an alarm log file parser 206, need only specify 208 the group of alarm token names 
10 necessary to trigger thereof in support of concurrent network management functionality 
(204). The use of combined alarm log files 102 in reporting alarm information greatly 
reduces overheads associated with log file management. 

[28] In accordance with the exemplary embodiment of the invention, the XML tags 
employed to encapsulate alarm tokens act, as shown above, as alarm log file section 
15 separation markers enabling the parser 206 to identify the body of alarm reports in the 
alarm log file 102. 

[29] In accordance with the exemplary embodiment of the invention, alarm token 
delimiters are no longer necessary as the XML tags may encapsulate simple and 
complex tokens in the same unified manner. 

20 [30] Multiple independent communications network equipment development efforts 
undertaken by multiple vendors, in implementing the exemplary embodiment of the 
invention, need only re-code a communications network equipment alarm reporting 
routine (function) 104, whether ITU X.733 compliant or not, with the ability to insert 
XML tags into alarm reports 100 as delimiter markers for each alarm token. 

25 [31] The XML markers themselves may not be hardcoded in, although hardcoding 
XML tags into alarm reporting code (104) is not excluded as an implementation of the 
exemplary embodiment of the invention. In order to provide implementation flexibility, 
an alarm code, specific to each vendor communication network equipment type 106, 
may be used as a key to in querying a table 108 of alarm code indexed XML tags for use 

30 in reporting the alarm identified by the alarm code. The alarm code indexed alarm code 
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table 108 enables XML tag specification independent of the communication network 
equipment development. 

[32] In accordance with the exemplary embodiment of the invention, vendor provided 
documentation regarding alarms reported by a particular communication network 
5 equipment 106 includes publishing the XML tags employed in respect of the alarms 
without a need to publish alarm codes. 

[33] Should particular legacy vendor communication network equipment 306 be no 
longer supported by the vendor, in accordance with another implementation of the 
exemplary embodiment of the invention, an alarm report translator 308 may be provided 

10 in respect of the particular legacy vendor communication network equipment 306, the 
alarm report translator 308 implementing current alarm report parsing techniques to 
identify the specific reported alarms in legacy alarm reports 300 and legacy alarm log 
files 302, and replace the current delimiters of the alarm reporting format with 
compliant alarm specific XML tags. Employing the alarm reporting translator 308 

15 reduces development overheads in supporting legacy communications network 
equipment 306. 

[34] In accordance with the exemplary embodiment of the invention, network 
management system developers need only employ XML parsing techniques in 
implementing the parser 206 for the NMS 202. The XML parser 206 employs the 

20 published XML tags and alarm token format information, provided and updated 
independently of each other, to parse alarm reports 100 and alarm log files 102. 
Regardless of the sequence in which alarm tokens of a specific alarm are reported in a 
single alarm log file 102, and irrespective of the number of reported alarm tokens 
present in respect of each alarm report 100, specific network management functions 204 

25 are triggered 210 based on the presence of specified groups of XML tag encapsulated 
alarm tokens concurrently and independent of the other network management functions 
204. Therefore network management functionality 104 may be employed despite 
further development with respect to reported alarms (100). 

[35] To the extent that previously employed alarm tokens in respect of a particular 
30 alarm are no longer employed, only network management functions 204 which required 
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the presence of the particular alarm token are affected, the rest of the network 
management functions 204 continue to respond to the reported alarms (100/102) as the 
sequence of XML encapsulated tokens is no longer important. 

[36] In accordance with the exemplary embodiment of the invention, should an alarm 
report a new alarm token, all network management functions 204 would continue to 
operate in responding to the reported alarms because the sequence of XML encapsulated 
tokens is no longer important as the parser 206 disregards alarm tokens encapsulated in 
unknown XML tags. The parser 206 need only be provided with an updated XML tag 
publication to recognize the new XML tags. Only network management functions 204 
requiring information reported via the new alarm tokens need be updated independently 
of the other network management functions 204. 

[37] In accordance with the exemplary embodiment of the invention, should a new 
alarm be reported, all network management functions 204 would continue to operate in 
responding to all previously known reported alarms (100/102) as the parser 206 
15 disregards alarm tokens encapsulated in unknown XML tags. The parser 206 need only 
be provided with an updated XML tag publication to recognize the new XML tags and 
therefore the newly reported alarm. Only network management functions 204 requiring 
information reported via the new alarm need be updated independently of the other 
network management functions 204. 

20 [38] In accordance with another implementation of the exemplary embodiment of the 
invention, should a legacy network management system 312 employing a legacy parser 
316 be used in a heterogeneous communications network management context in 
combination with compliant network management systems 202, backwards 
compatibility therewith may simply be achieved by stripping 314 all XML tags and 

25 introducing appropriate alarm token delimiters between the alarm tokens. 

[39] The embodiments presented are exemplary only and persons skilled in the art 
would appreciate that variations to the above described embodiments may be made 
without departing from the spirit of the invention. The scope of the invention is solely 
defined by the appended claims. 
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